Wireless power transfer device authentication

ABSTRACT

A method for authentication for wireless power transfer which comprises: receiving an initial certificate signed using a private key associated with an intermediate certificate authority (CA) certificate; determining that the intermediate CA certificate is revoked; determining if a replacement certificate for the initial certificate exists; and if a replacement certificate for the initial certificate exists, trusting a wireless power transfer device associated with the initial certificate.

FIELD

This relates generally to wireless power transfer device authentication.

BACKGROUND

Wireless power transfer devices may interact to transfer power. Forexample, a wireless power transmitter may transmit power to a wirelesspower receiver. In some cases, an authentication process may occurbefore wireless power transfer starts.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an illustrative wireless power systemin accordance with some embodiments.

FIG. 2 is a flow chart of an approach for authentication between twowireless power transfer devices in accordance with some embodiments.

FIG. 3 is a flow chart of an approach for obtaining a certificaterevocation list in accordance with some embodiments.

FIG. 4 is a flow chart of an approach for using a certificate revocationlist in accordance with some embodiments.

FIG. 5 is a flow chart of an approach for obtaining a certificatereplacement list in accordance with some embodiments.

FIG. 6 is a flow chart of an approach for using a replacementcertificate in accordance with some embodiments.

DETAILED DESCRIPTION

A wireless power system has a wireless power transmitting device (whichmay also be referred to in some instances as a wireless powertransmitter or an inductive power transmitter) that transmits powerwirelessly to a wireless power receiving device (which may also bereferred to in some instances as a wireless power receiver or aninductive power receiver). The wireless power transmitting device is adevice such as a wireless charging mat, wireless charging puck, wirelesscharging stand, wireless charging table, or other wireless powertransmitting equipment. The wireless power transmitting device may be astand-alone device or built into other electronic devices such as alaptop or tablet computer, cellular telephone or other electronicdevice. The wireless power transmitting device has one or more coilsthat are used in transmitting wireless power to one or more wirelesspower receiving coils in the wireless power receiving device. Thewireless power receiving device is a device such as a cellulartelephone, watch, media player, tablet computer, pair of earbuds, remotecontrol, laptop computer, electronic pencil or stylus, other portableelectronic device, or other wireless power receiving equipment.

During operation, the wireless power transmitting device suppliesalternating-current signals to one or more wireless power transmittingcoils. This causes the coils to generate an alternating magnetic fieldand to transmit alternating-current electromagnetic signals (sometimesreferred to as wireless power signals) to one or more correspondingcoils in the wireless power receiving device. Rectifier circuitry in thewireless power receiving device converts received wireless power signalsinto direct-current (DC) power for powering the wireless power receivingdevice.

Wireless power transmitting and receiving devices can be designed tocooperate specifically with each other. For example, the size, shape,number, dimensions and configuration of coils of one or both of thedevices may be selected based on the other device. Magnetic elements mayalso be included in the transmitting and/or receiving device, and thesize, shape, number, dimensions and configuration of the magneticelements may be selected based on the other device.

In some cases, wireless power transmitting and receiving devices can bedesigned to be closely coupled to each other. Typically, this isachieved by arranging the coils of the transmitting and receivingdevices such that they are aligned with and close to each other in use.Systems in which the transmitting and receiving devices can be closelycoupled to each other in use are sometimes referred to as inductivepower transfer systems. Transmitting and receiving devices that can beclosely coupled to receiving devices can be referred to as inductivepower transfer devices.

Wireless power transmitting and receiving devices can also be designedto cooperate with each other in particular orientations, positions orother spatial relationships. For example, some receiving devices mayhave a preferred position or orientation with respect to a transmittingdevice. This preferred position or orientation may allow for goodcoupling for efficient power transfer, minimum leakage of the magneticfield and other advantageous effects. The transmitting and/or receivingdevices may have visual markings to indicate where or in whatorientation to place the receiving device, engaging elements to hold thereceiving device in a particular position or orientation, magneticcouplings or other biasing elements to urge the receiving device towardsa particular position or orientation, or other arrangements.

Wireless power transmitting and receiving devices can also be used withother devices without being specifically designed to cooperate withthem. For example, a wireless power transmitting device can operate withmany different types of receiving devices having different coilarrangements, different (or no) magnetic elements, sizes, shapes andother characteristics. A wireless power receiving device can operatewith many different types of transmitting devices having different coilarrangements, different (or no) magnetic elements, sizes, shapes andother characteristics.

Wireless power transmitting and receiving devices can also be used invarious orientations, positions or other spatial relationships. Forexample, wireless power transmitting or receiving devices may beprovided without visual markings, engaging elements, magnetic couplingsor other biasing elements, or other arrangements. Alternatively,transmitting or receiving devices may have these arrangements but stilloperate in various other orientations and positions.

The term “coil” may include an electrically conductive structure wherean electrical current generates a magnetic field. For example, inductive“coils” may be electrically conductive wire in three dimensional shapesor two dimensional planar shapes, electrically conductive materialfabricated using printed circuit board (PCB) techniques into threedimensional shapes over plural PCB “layers”, and other coil-like shapes.Other configurations may be used depending on the application. The useof the term “coil”, in either singular or plural, is not meant to berestrictive in this sense.

An illustrative wireless power system is shown in FIG. 1. As shown inFIG. 1, a wireless power system 8 includes a wireless power transmittingdevice 12 (which may also be referred to in some instances as aninductive power transmitter) and one or more wireless power receivingdevices such as wireless power receiving device 10 (which may also bereferred to in some instances as an inductive power receiver). Device 12may be a stand-alone device such as a wireless charging mat, may bebuilt into furniture, laptop or tablet computers, cellular telephones orother electronic devices, or may be other wireless charging equipment.Device 10 is a portable electronic device such as a wristwatch, acellular telephone, a tablet computer, an electronic pencil or stylus,or other electronic equipment. Illustrative configurations in whichdevice 12 is a tablet computer or similar electronic device and in whichdevice 10 is an electronic accessory that couples with the tabletcomputer or similar electronic device during wireless power transferoperations may sometimes be described herein as examples. For example,in one embodiment electronic device 10 is a tablet computer andelectronic device 12 is a stylus configured to attach to electronicdevice 10 (tablet) and be wirelessly (e.g., inductively) charged byelectronic device 10 (tablet). Illustrative configurations in whichdevice 12 is a mat or other equipment that forms a wireless chargingsurface and in which device 10 is a portable electronic device orelectronic accessory that rests on the wireless charging surface duringwireless power transfer operations may also sometimes be describedherein as examples.

During operation of system 8, a user places one or more devices 10 on ornear the charging region of device 12. Power transmitting device 12 iscoupled to a source of alternating-current voltage such asalternating-current power source 50 (e.g., a wall outlet that suppliesline power or other source of mains electricity), has a battery such asbattery 38 for supplying power, and/or is coupled to another source ofpower. A power converter such as AC-DC power converter 40 can beincluded to convert power from a mains power source or other AC powersource into DC power that is used to power control circuitry 42 andother circuitry in device 12. During operation, control circuitry 42uses wireless power transmitting circuitry 34 and one or more coils 36coupled to circuitry 34 to generate an alternating magnetic field and totransmit alternating-current wireless power signals 48 to device 10 andthereby convey wireless power to wireless power receiving circuitry 46of device 10.

Power transmitting circuitry 34 has switching circuitry (e.g.,transistors in an inverter circuit) that are turned on and off based oncontrol signals provided by control circuitry 42 to create AC currentsignals through appropriate coils 36. As the AC currents pass through acoil 36 that is being driven by the switching circuitry, a time-varyingmagnetic field (wireless power signals 48) or “flux” is generated, thatis received by one or more corresponding coils 14 electrically connectedto wireless power receiving circuitry 46 in receiving device 10. If thetime-varying magnetic field is magnetically coupled to coil 14, an ACvoltage is induced and a corresponding AC currents flows in coil 14.Rectifier circuitry in circuitry 46 can convert the induced AC voltagein the one or more coils 14 into a DC voltage signals for poweringdevice 10. The DC voltages are used in powering components in device 10such as display 52, touch sensor components and other sensors 54 (e.g.,accelerometers, force sensors, temperature sensors, light sensors,pressure sensors, gas sensors, moisture sensors, magnetic sensors,etc.), wireless communications circuitry 56 for communicating wirelesslywith control circuitry 42 of device 12 and/or other equipment, audiocomponents, and other components (e.g., input-output devices 22 and/orcontrol circuitry 20) and/or are used in charging an internal battery indevice 10 such as battery 18, or to charge subsequent devices, eitherwired or wirelessly.

Devices 12 and 10 include control circuitry 42 and 20. Control circuitry42 and 20 may include storage and processing circuitry such as analoguecircuitry, microprocessors, power management units, baseband processors,digital signal processors, field-programmable gate arrays,microcontrollers, application-specific integrated circuits withprocessing circuits and/or any combination thereof. Control circuitry 42and 20 is configured to execute instructions for implementing desiredcontrol and communications features in system 8. For example, controlcircuitry 42 and/or 20 may be used in sensing for foreign or othernon-receiver objects (e.g.: metallic objects such as coins or RFID tagswithin electronic devices), determining power transmission levels,processing sensor data, processing user input, processing otherinformation such as information on wireless coupling efficiency fromtransmitting circuitry 34, processing information from receivingcircuitry 46, using information from circuitry 34 and/or 46 such assignal measurements on output circuitry in circuitry 34 and otherinformation from circuitry 34 and/or 46 to determine when to start andstop wireless charging operations, adjusting charging parameters such ascharging frequencies, coil assignments in a multi-coil array, andwireless power transmission levels, and performing other controlfunctions. Control circuitry 42 and/or 20 may be configured to performthese operations using hardware (e.g., dedicated hardware or circuitry)and/or software (e.g., code that runs on the hardware of system 8).Software code for performing these operations is stored onnon-transitory computer readable storage media (e.g., tangible computerreadable storage media). The software code may sometimes be referred toas software, data, program instructions, instructions, or code. Thenon-transitory computer readable storage media may include non-volatilememory such as non-volatile random-access memory (NVRAM), one or morehard drives (e.g., magnetic drives or solid state drives), one or moreremovable flash drives or other removable media, other computer readablemedia, or combinations of these computer readable media or otherstorage. Software stored on the non-transitory computer readable storagemedia may be executed on the processing circuitry of control circuitry42 and/or 20. The processing circuitry may include application-specificintegrated circuits with processing circuitry, one or moremicroprocessors, or other processing circuitry.

Device 12 and/or device 10 may communicate wirelessly. Devices 10 and 12may, for example, have wireless transceiver circuitry in controlcircuitry 42 and 20 (and/or wireless communications circuitry such ascircuitry 56 of FIG. 1) that allows wireless transmission of signalsbetween devices 10 and 12 (e.g., using antennas that are separate fromcoils 36 and 14 to transmit and receive unidirectional or bidirectionalwireless signals, using coils 36 and 14 to transmit and receiveunidirectional or bidirectional wireless signals, etc.). For example,device 12 and/or device 10 may communicate using in-band communicationsinjected or combined into the wireless power signals 48 such as proposedin the Wireless Power Consortium Qi specification 1.2.3, which isincorporated herein by reference. Alternatively, a separate Bluetooth,RFID, NFC, Zigbee, WiFi, RF or other communication system may beemployed.

Authentication

In some cases, it may be useful for a first “initiator” device toestablish trust in a second “responder” device before wireless powertransfer starts. Additionally or alternatively, the initiator device mayestablish trust in the responder device before the initiator deviceprovides enhanced or premium functionality, if this is intended to bedependent on trusting that the responder exhibits compliant behaviorspecified by a standards organization (such as a certification lab oragency). A first wireless power transfer device adopting the role of theinitiator (such as a wireless power transmitter or wireless powerreceiver) may attempt to authenticate a second wireless power transferdevice adopting the role of the responder (such as a wireless powerreceiver or wireless power transmitter). This may occur by the secondwireless power transfer device (the responder) sending a certificate ora certificate chain containing a public key for the second wirelesspower transfer device to the first wireless power transfer device(initiator). The certificate, or certificates within the certificatechain, are digitally signed by one or more certificate authorities(CAs). By validating the digital signatures, the first wireless powerdevice (initiator) can establish trust in the certificate provided bythe second wireless power device. The initiator device may then verifythat the responder device owns the certificate by issuing a challengenonce message. The responder can use a private key to produce a digitalsignature that proves to the initiator that the responder is inpossession of a private key that corresponds to the public key containedwithin the trusted certificate. The initiator is thus able to establishtrust in a responder that proves that the responder possesses a privatekey corresponding to the public key of a certificate digitally signed byan entity or entities trusted by the initiator.

This makes use of public-key cryptography. Public-key cryptography is acryptosystem which uses a complementary pair of keys: a public key whichcan be freely available and a private key which is kept secret. Thepublic key and private key are chosen such that a message is encryptedor verified as authentic by using a first of either the public key orthe private key to produce a ciphertext result that can be decrypted orhave been signed using the other of the public key and private key. Thisallows for a public key to be used to encrypt or verify a message whichonly the holder of the private key can decrypt or sign. The public keyand private key may be stored in a compressed format or representedusing elliptic-curve cryptography or any other approach. The public keyand private key may be assigned or chosen by using any approach that hasthe property of a cryptographic one-way hash function which makes itinfeasible to determine a private key from a given public key andciphertext signatures or encrypted messages.

FIG. 2 shows an approach to authentication between two wireless powertransfer devices. The first wireless power transfer device (such as awireless power transmitter) may be an initiator and a second wirelesspower transfer device (such as wireless power transmitter) may be aresponder. The initiator is the party which is attempting to verifywhether the responder can be trusted. The responder is the party whichis trying to prove that it can be trusted.

At step 201, the initiator requests a certificate chain for theresponder.

The initiator may send a suitably configured message to the responder.This may occur after an initial handshake between the initiator and theresponder occurs to establish communication between the initiator andthe responder.

In some cases, only a certificate is requested, instead of a certificatechain. For example, if a certificate is signed directly by a root CA,only the certificate may be requested.

At step 202, the initiator receives the certificate chain for theresponder.

The certificate chain comprises a sequence of certificates. Eachcertificate is issued by an issuer (such as a CA) for a subject (such asa wireless power transfer device or other CA). The purpose of acertificate is for the issuer to vouch for the subject. On receiving thecertificate, if the issuer and its signature for the certificate can betrusted, then the subject of the certificate can be trusted. Thesignature and contents of a certificate can be trusted whencryptographic criteria are satisfied when combined with a trusted publickey to establish that the signature was produced for the certificate incombination with the corresponding private key.

Each certificate may comprise a serial number uniquely assigned by theissuer, an identifier of the issuer, and a public key for the subject,and a signature. The signature is a hash (such as a SHA-256 hash) ofpredetermined contents of the certificate (such as the serial number,the identifier of the issuer, and the public key) encrypted using aprivate key of the issuer.

The identifier of the issuer may be a reference to another certificate.For example, the identifier of the issuer may the hash or serial numberof another certificate.

To verify a certificate, the public key of the issuer may be obtainedfrom another trusted certificate via wide area network, firmware update,or stored in the device during manufacture. This can be identified usingthe identifier of the issuer. If this public key can be successfullycombined with a hash value (such as a SHA-256 hash value) formed fromthe certificate content to satisfy the cryptographic criteria thatestablishes that the private key was used to produce the signature, thisverifies that the signature was generated by the issuer. This is becauseit is infeasible (that is, expected to be impossible within a reasonabletime frame and with reasonable computing resources) to compute a privatekey from a public key. Therefore, assuming a private key is secret, onlythe party which holds that private key could generate a certificatesignature that will fulfill the cryptographic criteria produced by thecorresponding public key and the certificate content.

The certificate chain comprises a sequence of certificates. A chain maybegin with a root CA certificate that is implicitly trusted bypossession, or by virtue of having been provisioned to the device via atrusted source such as during the manufacturing process. Since the rootCA certificate or at least its public key may be provisioned within theinitiator device in order that it may trust a certificate chainpublished by a responder device, the root CA certificate may be omittedfrom the certificate chain published by a responder to reduce storagespace. Where the root certificate is omitted from the certificate chain,it may be replaced by a signature of the root CA certificate tofacilitate identification or verification of the correct root CAcertificate. For example, in a certificate chain published by aresponder device, there may be a root CA certificate signature and atleast two certificates: one for an intermediate CA (such as amanufacturer of a wireless power transfer device), and one for a device(such as the wireless power transfer device).

A first certificate (such as an intermediate CA certificate) in apublished certificate chain is signed by a root CA. This means that thefirst published certificate comprises a public key for verifying thenext certificate and a signature from the root CA to authenticate thecertificate. The signature may be a hash of certain contents of thefirst certificate and then encrypted using a private key of the root CA.

Each subsequent certificate in the certificate chain has a signaturegenerated using a private key corresponding to a public key of apreceding certificate. That preceding certificate may be identifiedusing the identifier of the issuer. So, a second certificate in thecertificate chain has a signature encrypted using a private keycorresponding to a public key in the first certificate in thecertificate chain.

The final certificate in the certificate chain corresponds to theresponder.

At step 203, the initiator verifies the certificates in the certificatechain. This may involve determining, for each certificate within thecertificate chain, whether there is a signature for the certificategenerated by a trusted CA.

The first certificate in the published certificate chain is signed by aroot CA. The public key of the root CA may be known in advance. Wherethe root CA uses multiple public-public key pairs and thus multiple rootCA certificates, the certificate chain may indicate which rootcertificate is to be used, for example by publishing an identifier as ahash (such as a SHA-256 hash) of the root CA certificate for theappropriate public-private key pair that is being used. The signature inthe first certificate is then encrypted using the appropriate public keyfor use by the root CA. For example, this may involve using anelliptic-curve digital signature algorithm (ECDSA) such as ANSI standardX9.62-2005 to generate a signature of predetermined contents of thecertificate, excluding the signature itself. If the signatureverification process computed on the certificate contents, signature,and the public key is successful, this proves that the signature wasgenerated using the private key possessed by the root CA. This isbecause the private key of a root CA is secret, such that only that rootCA could generate the signature. Since root CAs are implicitly trusted,the root CA certificate (and a public key in the root CA certificate)must be trustfully provisioned within an initiator device so that it canbe trusted. It may thus be replaced by a plain hash signature, such as aSHA-256 hash, in the certificate chain published by a responder device.

Each subsequent certificate is verified using the public key of thepreceding certificate. Since the issuer of the preceding certificate hassigned each subsequent certificate, since the preceding certificate hasalready been verified, and since only the issuer of the precedingcertificate is expected to have the private key required to sign such asubsequent certificate, this allows each subsequent certificate to betrusted. This provides a chain of trust. That is, there is a sequence ofcertificates which provide that as long as the root CA is trusted, thepublic key of the device can be trusted.

Conversely, if one of the certificates in the certificate chain cannotbe verified, then the verification fails. This may result in theinitiator foregoing wireless power transfer with the responder.Alternatively, this may result in the initiator implementing a systempolicy behavior for untrusted devices such as foregoing wireless powertransfer at a higher power (such as around 10 W) with the responder, andinstead providing wireless power transfer at a lower power (such asaround 5 W).

A result of verifying the certificate chain may be that a device whichhas a private key corresponding to the public key can be trusted.

It may remain to determine that the responder has a private keycorresponding to the trusted public key. That is, a responder being ableto provide a valid certificate chain may not be sufficient to prove thatthe certificate chain relates to that responder.

Determining this may involve a challenge-response authenticationprocess. In some cases, this may occur before step 201, 202, and 203.This would mean that the device proves it has a particular private keybefore determining whether a device having that private key is trusted.

At step 204, the initiator sends a challenge to the responder. Thechallenge may be a message comprising a nonce (such as a random 128-bitnumber).

At step 205, the initiator receives a response to the challenge. Theresponse comprises a digital signature for the nonce encrypted using theresponder's private key. This encryption may use the elliptic curvedigital signature algorithm (ECDSA) specified in ANSI standardX9.62-2005 in combination with a SHA-256 hash value computed from thenonce.

At step 206, the initiator verifies the response, for example by usingthe elliptic curve digital signature algorithm (ECDSA) specified in ANSIstandard X9.62-2005. This may involve decrypting theprivate-key-encrypted hash value of the nonce by using the public keyassociated with the device. If this results in the non-encrypted hashvalue of the nonce, then this is proof that the responder has theprivate key corresponding to the public key. If this does not result inthe non-encrypted hash value of the nonce, then the verification fails.Alternatively, use of ECDSA may instead look for equal values of theposition co-ordinate “x” published as an ECDSA signature component value“r”, with that of the position co-ordinate “x” determined by theelliptic curve point representation of a value computed from the hashvalue, public key, and ECDSA signature component value “s”. Failedverification may result in the initiator foregoing wireless powertransfer with the responder. Alternatively, failed verification mayresult in the initiator implementing a system policy behavior foruntrusted devices such as foregoing wireless power transfer at a higherpower (such as around 10 W) with the responder, and instead providingwireless power transfer at a lower power (such as around 5 W).

The verification of step 206 complements the verification of step 203.That is, a result of step 203 is that a device having a particularprivate key can be trusted. A result of step 206 is that the responderhas that private key. Therefore, a result of these steps in combinationis that the responder can be trusted.

At step 207, the initiator may start wireless power transfer with thetrusted responder. This may involve the initiator starting to provide asustained flow of wireless power to allow for charging and/or powering aload at the trusted responder. This may be in accordance with a systempolicy behavior for trusted devices, such as permitting wireless powertransfer at a higher power (such as around 10 W), in contrast to a lowerpower (such as around 5 W) permitted for untrusted devices.

In some cases, further authentication, configuration, or otherinteraction may occur between the initiator and the responder beforestep 207 occurs.

As noted above, verification performed at step 203 assumes that if anissuer's private key has been used to sign a certificate, then only theissuer could have generated that signature. That is, private keys areassumed to be secret to the issuer.

If a private key is compromised (for example, by being made public),this means that a certificate may be signed by a party other than theissuer. A signature generated using that private key is then no longersufficient to prove that the issuer vouches for the subject of thecertificate. Any certificate signed with that private key should nolonger be considered valid.

When a private key is compromised, it can be useful to advise initiatorsof this compromise. In some cases, this may be implemented using acertificate revocation list. The certificate revocation list comprises alist identifying any certificate having a public key corresponding to aprivate key that has been compromised.

That is, when an intermediate CA is an issuer of a certificate in acertificate chain, then that certificate chain comprises an intermediateCA certificate which has a public key of the intermediate CAcorresponding to a private key of that intermediate CA.

If that private key is compromised, the intermediate CA certificatewhich comprises a public key corresponding to that private key can beadded to the certificate revocation list.

The certification revocation list may be propagated to initiatorsperiodically. If a certificate chain contains a certificate on thecertificate revocation list, then the certificate chain may not beverified.

FIG. 3 shows an example of how an initiator may obtain a certificaterevocation list.

At step 301, the initiator obtains a certificate revocation list.

Obtaining the certificate revocation list may occur by the initiatorobtaining the certificate revocation list from a trusted source. Theroot CA may maintain an URL which links to a current certificaterevocation list.

The certificate revocation list may be signed by a trusted party, suchas a root CA. For example, the certificate revocation list may comprisea signature computed from a hash, such as an ECDSA X9.62 signaturecomputed from a SHA-256 hash, of the list of revoked certificatesencrypted with a private key of the root CA.

At step 302, the initiator verifies the certificate revocation list.

This may involve verifying a signature of the certificate revocationlist, for example by using ECDSA X9.62 to verify the signature using apublic key of the root CA and a calculated hash of the list of revokedcertificates. If the signature verification process is successful, thecertificate revocation list can be trusted to have been validated orpublished by the root CA.

At step 303, the initiator stores the certificate revocation list.

This allows the certificate revocation list to be used subsequentlyduring certificate verification.

While steps 301 to 303 may occur in every authentication process, inmany cases, steps 301 to 303 occur less frequently. Updates to thecertificate revocation list may be pushed to initiators, such that theinitiator is caused to perform steps 301 to 303 when the certificaterevocation list is changed or republished. Additionally oralternatively, steps 301 to 303 may occur periodically (such as everythree months), or whenever the initiator receives an update as part of afirmware or software update process.

FIG. 4 shows an example of how an initiator may use the certificaterevocation list in verifying a certificate chain.

At step 401, the initiator receives a certificate chain. This may be thesame as step 202.

At step 402, each certificate in the certificate chain is compared tothe certificate revocation list.

If a certificate in the certificate chain matches a certificate in thecertificate revocation list, the certificate (and thus a certificatechain comprising that certificate) may not be verified.

If any certificate in the certificate chain has been revoked, then anysubsequent certificates in that certificate chain cannot be trusted.This is because it is unknown whether the issuer has signed thesubsequent certificate or whether an intervening party has obtained thecompromised private key and signed the subsequent certificate.

Therefore, a certificate chain which comprises a revoked certificate maynot be verified even the certificate chain otherwise comprises a validchain of signed certificates.

In some cases, step 203 may comprise the approach of FIG. 4.

An effect of a certificate revocation list may be that certificatechains of devices become invalid if an intermediate CA certificate hasbeen revoked. This means a device may become untrusted despite therebeing no change to the device at all. If a valid certificate chain is aprerequisite for selectively obtaining behaviors defined as theinitiator's system policy for trusted devices, this may mean that anotherwise fully operable device is no longer able obtain behaviorsdefined as the initiator's system policy for trusted devices, forexample wireless power transfer at a higher power (such as around 10 W)rather than a lower power (such as around 5 W). Because of this,revoking intermediate CA certificates may involve a lot of collateraldamage, by rendering some features of operable devices inoperable orless operable.

Replacement Certificates

One approach to mitigate collateral damage caused by revoking anintermediate CA certificate is to make use of replacement certificates.

When an initiator finds that a certificate in a certificate chain for aresponder is revoked, the initiator may determine whether a replacementcertificate chain for that certificate exists. If a replacementcertificate chain exists, the replacement certificate chain may betreated as if it had been provided by the responder device itself.

A replacement certificate chain's last certificate (which may be aproduct unit certificate) may comprise a public key for the responderand a serial number of the certificate in the certificate chain. Thepublic key and the serial number in the replacement certificate aretypically identical to those of the certificate in the certificate chainof the responder which was signed by the revoked intermediate CAcertificate. This replacement certificate can be used to validate aresponder's certificate even where the signature in the certificate canno longer be trusted.

The replacement certificate chains may be generated when an intermediateCA certificate should be revoked. These may be generated based onrecords at the intermediate CA of signatures which were signed using theprivate key for that intermediate CA certificate. The records of anintermediate CA typically indicate the serial number and the public keyof the certificates that were signed throughout the operating life ofthe CA.

The replacement certificate chains may be in a certificate replacementlist which is distributed to initiators.

FIG. 5 shows an example approach for how the certificate replacementlist is obtained.

At step 501, the initiator obtains a certificate revocation list. Asnoted above in FIG. 3, this may occur in different ways.

At step 502, the initiator obtains a location for one or morereplacement certificate lists in the certificate revocation list. Eachreplacement certificate list may correspond to one entry in thecertificate revocation list, and the location may be in the certificaterevocation list associated with an entry of the certificate revocationlist. The location may be a URL (or more generally a pointer to a WAN,LAN, or other network location) which relates to a replacementcertificate list provided by a trusted party, such as a root CA. Thelocation may be referred to as a link.

At step 503, the initiator obtains a replacement certificate list. Thismay comprise downloading the replacement certificate list using thelocation information.

The certificate replacement list may be signed by a trusted party. Forexample, the certificate replacement list may comprise a hash, such as aSHA-256 hash, of the list of replacement certificates encrypted with aprivate key of the root CA, or by an ECSDA signature described by ANSIX9.62.

At step 504, the initiator verifies the certificate replacement list.

This may involve verifying the signature of the certificate replacementlist, for example by decrypting the signature using a public key of theroot CA and comparing the non-encrypted hash value decrypted from thesignature with the value calculated as a hash of the list of replacementcertificates. If these are identical, the certificate replacement listcan be trusted to have been validated or published by the root CA.Alternatively ECDSA described in ANSI X9.62 may be used to verify acorresponding ECDSA signature provided with the certificate replacementlist.

At step 505, the initiator stores the certificate replacement list.

This allows the certificate replacement list to be used subsequentlyduring certificate verification.

In alternative embodiments, the replacement certificate list isincorporated into the certification revocation list. By obtaining thecertificate revocation list, the initiator also obtains the replacementcertificate list.

FIG. 6 shows an approach for how replacement certificates may be used atan initiator.

At step 601, the initiator receives an initial certificate signed usinga private key associated with an intermediate CA certificate.

The initial certificate may be a certificate in a certificate chain of aresponder. The initial certificate may be a leaf certificate in thecertificate chain (that is, may be a certificate which comprises apublic key for the responder).

The initial certificate may have an identifier of a precedingcertificate in the certificate chain (such as the identifier of theissuer). This may be an identifier of the intermediate CA certificate.

At step 602, the initiator determines whether the intermediate CAcertificate is revoked.

This may involve querying a certificate revocation list for theintermediate CA certificate. If the preceding certificate for theinitial certificate is on the certificate revocation list, then theintermediate CA certificate is revoked. This means that any signaturegenerated using the private key corresponding to the public key in theintermediate CA certificate cannot be trusted to have been signed by theintermediate CA. The initial certificate is therefore not trusted.

At step 603, the initiator determines whether a replacement certificatefor the initial certificate exists.

This may involve obtaining a replacement certificate list (for example,using the approach shown in FIG. 5) and querying the certificatereplacement list for a replacement certificate for the initialcertificate. Querying may mean determining whether a public key and aserial number of the initial certificate appear on the certificatereplacement list.

If the replacement certificate exists with the same public key value,this can be used to determine that the initial certificate should betrusted even if the signature in the initial certification cannot betrusted. Because the replacement certificate list is issued by a trustedauthority, any initial certificate with a public key value correspondingto a replacement certificate list entry can be trusted. The replacementcertificate therefore acts as an alternative verification for thesignature of the initial certificate.

If the replacement certificate does not exist, then the initialcertificate remains untrusted. This may mean that the responder is notverified, and so the initiator may forego wireless power transmissionwith the responder.

Therefore, even if an intermediate CA certificate has been revoked(which would otherwise cause a certificate chain to be untrusted), aninitial certificate of a responder signed by the revoked intermediate CAmay still be verifiable through the replacement certificate list. Thismay allow an intermediate CA certificate to be revoked with reducedcollateral damage.

Moreover, because a replacement certificate need not contain anysensitive information, there is no need for replacement certificates tobe restricted access. For example, if a replacement certificate onlycontains a public key (which is inherently non-secret) and a serialnumber of the initial certificate, a malicious third party could not usethis replacement certificate to authenticate a different device. This isbecause while the replacement certificate would allow the differentdevice to emulate the trusted certificate chain, they may still not havethe private key and so may consequently fail a challenge-responseauthentication.

This therefore reduces the chance that a third party could impersonate atrusted device.

Certificate Authority

As noted above, the initiator may obtain a certificate revocation listand a replacement certificate list. In some cases, these are provided bya CA (such as a root CA).

In response to one or more requests, the CA may provide a certificaterevocation list comprising one more revoked intermediate CAcertificates. The CA may further provide a replacement certificate list.Each entry of this may relate to an initial certificate of a wirelesstransfer device, such as a responder, which has been signed by a privatekey corresponding to a public key of one or more of the revokedintermediate CA certificates.

The certificate revocation list and/or the replacement certificate listmay be themselves signed using a private key of the CA. This can allow arecipient (such as an initiator) to verify that the certificaterevocation list and/or the replacement certificate list were issued bythe CA. Alternatively the replacement certificate list may incorporate areplacement intermediate certificate from another trusted intermediateCA to re-establish a chain of trust from the root CA to the replacementproduct unit certificate that incorporates a new signature.

The foregoing is merely illustrative and various modifications can bemade to the described embodiments. The foregoing embodiments may beimplemented individually or in any combination, and elements from oneembodiment may be combined with others.

1. A method for authentication for wireless power transfer, the methodcomprising: receiving an initial certificate signed using a private keyassociated with an intermediate certificate authority (CA) certificate;determining that the intermediate CA certificate is revoked; determiningif a replacement certificate for the initial certificate exists; and ifthe replacement certificate for the initial certificate exists, causingwireless power transfer to a device associated with the initialcertificate.
 2. The method of claim 1, wherein if the replacementcertificate for the initial certificate does not exist, the methodfurther comprises one of: foregoing wireless power transfer to thedevice associated with the initial certificate; and initiating wirelesspower transfer with the device in accordance with a system policy of theinitiator for untrusted devices.
 3. The method of claim 1, whereindetermining that the intermediate CA certificate is revoked comprises:querying a certificate revocation list for the intermediate CAcertificate.
 4. The method of claim 1, further comprising obtaining areplacement certificate list; and querying the replacement certificatelist for a replacement certificate for the initial certificate.
 5. Themethod of claim 4, wherein the replacement certificate list comprisesone or more public keys, each public key being associated with a revokedintermediate CA certificate.
 6. The method of claim 5, wherein queryingthe replacement certificate list for a replacement certificate for theinitial certificate comprises: determining if the replacementcertificate list comprises a public key of the initial certificate. 7.The method of claim 4, wherein obtaining the replacement certificatelist comprises: obtaining a link from a certificate revocation list, thelink being associated with an entry in the certificate revocation list,the entry associated with the intermediate CA certificate; and obtainingthe replacement certificate list using the link.
 8. The method of claim4, wherein obtaining a replacement certificate list comprises: obtaininga certificate revocation list, wherein the certificate revocation listcomprises the replacement certificate list.
 9. The method of claim 4,wherein the replacement certificate list is signed by a root CA.
 10. Themethod of claim 4, wherein the initial certificate comprises a publickey, and the replacement certificate comprises the public key.
 11. Themethod of claim 4, wherein the replacement certificate comprises aserial number of the initial certificate.
 12. The method of claim 1,wherein receiving an initial certificate comprises: requesting theinitial certificate from the device.
 13. The method of claim 1, furthercomprising: performing challenge-response authentication with thedevice.
 14. The method of claim 13, wherein if the challenge-responseauthentication is successful, the method further comprises one of:initiating wireless power transfer with the device; and initiatingwireless power transfer with the device in accordance with a systempolicy of the initiator for trusted devices.
 15. The method of claim 14,wherein initiating wireless power transfer with the device in accordancewith a system policy of the initiator for trusted devices comprises:initiating wireless power transfer with the device at a higher power.16. The method of claim 13, wherein if the challenge-responseauthentication is not successful, the method further comprises one of:foregoing wireless power transfer with the device; and initiatingwireless power transfer with the device in accordance with a systempolicy of the initiator for untrusted devices.
 17. The method of claim16, wherein initiating wireless power transfer with the device inaccordance with a system policy of the initiator for untrusted devicescomprises: initiating wireless power transfer with the device at a lowerpower.
 18. The method of claim 1, further comprising: if the replacementcertificate for the initial certificate does not exist, determining thata device associated with the initial certificate is untrusted.
 19. Themethod of claim 18, further comprising: if the device associated withthe initial certificate is untrusted, foregoing wireless power transferwith the device.
 20. The method of claim 1, wherein the initialcertificate is part of a certificate chain.
 21. The method of claim 1,wherein the device is a wireless power transmitter.
 22. The method ofclaim 1, wherein the device is a wireless power receiver.
 23. A wirelesspower transfer device configured to perform the method of claim 1,wherein the wireless power transfer device is one of a wireless powerreceiver and a wireless power transmitter.
 24. A system for acertificate authority, comprising: one or more processors; and a memory;wherein the memory comprises instructions which, when executed by theone or more processors, cause the one or more processors to: provide acertificate revocation list comprising one or more revoked intermediateCA certificates; and provide a replacement certificate list, each entryof the replacement certificate list being associated with a public keyof an initial certificate of a wireless transfer device, the initialcertificate being signed by one or more of the one or more revokedintermediate CA certificates.
 25. The system of claim 24, wherein thecertificate revocation list and/or the replacement certificate list aresigned by a private key associated with the system.